在學習大型系統的過程中，我一直遇到兩個很常出現的名詞：

System Design（系統設計）
System Architecture（系統架構）

一開始我其實也沒有特別去區分這兩件事情。

尤其在台灣的軟體業，這兩個詞很多時候是混在一起使用的。甚至你會看到「系統架構師」、「系統分析師」、「資深工程師」，實際上做的事情有非常大的重疊。

但後來我慢慢發現：

系統設計與系統架構確實有很大的交集，但兩者看事情的角度其實不太一樣。

而我覺得理解這個差異很重要。

因為很多時候，你遇到的問題根本不是「架構不好」，而是「系統設計出了問題」。

反過來也是一樣。

先不要急著談技術

假設今天公司要做一套提款系統。

需求看起來很簡單：

使用者申請提款 → 系統扣款 → 呼叫第三方支付商 → 等待結果 → 成功或失敗。

如果從 System Design 的角度來看，我可能會先開始想：

• 提款有哪些狀態？
• 狀態之間可以怎麼轉換？
• 第三方 Timeout 怎麼辦？
• Callback 重複進來怎麼辦？
• 扣款成功，但呼叫第三方失敗怎麼辦？
• 失敗後退款，要怎麼避免重複退款？
• 一筆交易卡了三天，要怎麼處理？
• 使用者重複送出同一筆請求怎麼辦？

你會發現，我們其實還沒有開始討論 Kafka、RabbitMQ、Redis 或 Kubernetes。

我們只是在思考：

「這套系統到底應該怎麼運作？」

這就是我認為 System Design 很重要的一個思考方向。

很多系統最後出問題，不是因為 Redis 用錯，也不是因為 Kafka 撐不住。

而是最一開始就沒有把「狀態」、「流程」、「一致性」、「失敗情境」想清楚。

那 System Architecture 在想什麼？

如果把視角再往外拉一點，問題就開始不一樣了。

例如我們現在有：

Payment Service、Wallet Service、Order Service、Provider Gateway。

這時候開始要思考：

到底誰應該負責什麼？

提款狀態應該由 Payment 管理，還是 Wallet 管理？

Wallet 可以直接呼叫 Provider 嗎？

Payment Service 可以直接修改 Wallet 的資料庫嗎？

服務之間應該走 REST API、gRPC，還是 Message Queue？

如果今天交易量增加十倍，哪些服務需要獨立 Scale？

某個 Provider 掛掉，會不會拖垮整個支付系統？

這時候我們考慮的事情，就慢慢從「一個系統應該怎麼運作」，變成：

「整個系統應該怎麼被切分，以及這些元件之間應該如何合作。」

這就是 Architecture 開始關心的事情。

它比較在意的是：

Boundary、Responsibility、Dependency、Communication、Scalability，以及整體的 Trade-off。

兩者其實不是上下級關係

我以前會很自然地認為：

System Design → System Architecture

好像先學 System Design，最後升級成 Architecture。

但後來我覺得這個理解不太準確。

它們比較像是用不同的視角看同一套系統。

System Design 比較常問：

「這個功能要怎麼正確運作？」

System Architecture 比較常問：

「這些能力應該放在哪裡？彼此怎麼合作？」

例如今天發生「重複退款」。

第一個直覺可能會覺得：

「是不是架構有問題？」

但你往下追之後可能發現，真正缺少的是退款流程的 Idempotency、狀態轉移限制，或者 Transaction Boundary 沒有定義好。

這比較接近 System Design 問題。

相反地，如果你發現每個 Service 都可以直接改其他 Service 的資料庫，任何一個功能修改都會牽動五六個系統，那就算每個流程本身都寫得很漂亮，問題可能還是在 Architecture。

因為系統的 邊界(Boundary) 與 責任(Responsibility) 本身就沒有切好。

「問題在哪一層」先定義好

這也是我開始學習 System Design 之後，一個很大的改變。

以前看到問題，很容易直接跳到技術：

「要不要加 Redis？」

「是不是要用 Kafka？」

「這邊要不要拆 Microservice？」

但現在我會先問：

我們現在到底在解什麼問題？

如果連提款有哪些狀態、失敗怎麼補償、誰可以改變狀態都還沒有定義清楚，那現在討論 Kafka 還太早。

相反地，如果流程已經很清楚，但是系統之間互相依賴、責任邊界混亂，那一直修改流程也不一定有用。

你需要處理的可能是 Architecture。

所以我認為學習 System Design 與 System Architecture，真正有價值的地方，不只是記住兩個名詞的定義。

而是建立兩種不同的思考方式。

下一次遇到系統問題時，可以先問自己：

這是一個 Design Problem，還是一個 Architecture Problem？

光是把問題放到正確的層次，限縮要考量的範圍，很多事情其實就會清楚很多。

問題思考

1. 當系統發生重複執行某個商業邏輯時，你會先檢查 Design 還是 Architecture？
2. 如果每個 Service 都可以修改其他 Service 的 Database，問題出在哪一層？
3. 如果一筆交易長時間停留在 Pending，卻沒有任何機制負責 Retry、Timeout 或 Compensation，這是 Design 還是 Architecture 的問題？